home *** CD-ROM | disk | FTP | other *** search
/ Aminet 7 / Aminet 7 - August 1995.iso / Aminet / docs / misc / ConcNews.lha / news / amiga.system / comp.sys.amiga.applications_2464_000009.msg < prev    next >
Encoding:
Internet Message Format  |  1994-11-27  |  4.0 KB
  1. Path: dd.chalmers.se!news.chalmers.se!sunic!pipex!uunet!zib-berlin.de!uniol!caty!aworld!roderick!klaatu
  2. From: KLAATU@RODERICK.zer.de
  3. Message-ID: <2yotQk6Ev7@RODERICK.zer.sub.org>
  4. Newsgroups: comp.sys.amiga.applications
  5. Subject: Re^2:We need TRUE multiple assigns
  6. Date: Fri, 14 Jan 94 03:04:00 CET
  7. Lines: 72
  8.  
  9. On Mi 12.01.1994 at 00:20:00 wrote user PETS%MUNTA.CS.MU.OZ.AU@AWORLD.zer.sub.org
  10. under the subject 'Re^1:We need TRUE multiple assigns':
  11.  
  12. PE> I'd really like to say that that should be configurable when you set
  13. PE> up the multi assign.  It would be nice if you could nominate any of
  14. PE> the directories in the multi assign as the one in which new files
  15. PE> should be created.  But this could have unfortunate consequences when
  16. PE> a file by that name already exists earlier in the multi assign than
  17. PE> the place where new files are created.  In that case, you'd create a
  18. PE> new file, but when you read it, you'd see the old file.  The new one
  19. PE> would fall into a sort of black hole:  it would be there, but hidden
  20. PE> by an older file.
  21. PE>
  22. PE> So I guess the multi assign needs to create new files the way it does
  23. PE> now: in the first constituent directory.  This guarantees that the new
  24. PE> file will be seen, meeting my goal that an assign should act just like
  25. PE> a directory, to the extent possible.
  26. PE>
  27. PE> There is a problem here, though.  A program that loads a file into
  28. PE> memory, makes some changes, and then writes the file back to disk,
  29. PE> e.g. a text editor, may have some problems.  If it reads the file from
  30. PE> the second directory in the assign, but writes it back into the first,
  31. PE> then it has in effect moved the file from one directory to another.
  32. PE> For example, if S: is assigned to bench:s and sys:s in that order, and
  33. PE> you edit s:startup-sequence, many editors would write your
  34. PE> startup-sequence to bench:s.  Of course, when your startup-sequence is
  35. PE> read, your multi assign for S: isn't set up yet, so the new
  36. PE> startup-sequence is not used.
  37. PE>
  38. PE> One solution to this would be for the multi assign to search the
  39. PE> constituent directories for a file of the same name as the file to be
  40. PE> created, and always write the file there.  This would give the correct
  41. PE> behavior, but seems kind of kludgey to me.  Still, it might be the
  42. PE> best solution, as it doesn't require programs to do anything special.
  43. PE>
  44. PE> It would help for the multi assign device/handler/file system to
  45. PE> respond to a call to Parent() by returning a lock on the directory in
  46. PE> which the file really lives.  This is probably what it ought to do
  47. PE> anyway.  In this case, constructing the full name from the locked file
  48. PE> would give its true name, and opening *this* file for writing will
  49. PE> write the file in the right place.  I doubt many programs do this,
  50. PE> though.  It's certainly not "the unix way."
  51.  
  52. Sorry for the long quoting, but you'll understand, when i say this:
  53.  
  54. There is real Multiple assign handler already: pathmanager taken from the
  55. WShell- distribution.
  56.  
  57. It handels multiple assigns in an own device. If you read such a assign, you'll
  58. get the first, visible file. Which is first depends of the entries in the
  59. assign-statement. if you write to this assign, the file is created in the first
  60. reachable directory. EXCEPT if the file allready exists in another directory.
  61.  
  62. So i have set up my S: as follows:
  63.  
  64. assign S: path:config:,OSX:script,sys:s
  65.  
  66. this means i write first in an directory called config: (another assign though),
  67. which is handy for all the programs that still use S: for configs and not ENV:.
  68. Then i have some Shell-Script-files in the chain and at last the original
  69. s-directory.
  70.  
  71. When i edit my startup-sequence it is rewritten in sys:s, not in config: because
  72. it pre-exists there. If i create a new file and save it to s: it actually gets
  73. created in config:
  74.  
  75. I use this goody since several years, actually since the time when my used bought
  76. copy of WShell 1.3 broke under 2.04 and 3.0. It still works well under the
  77. highest OS.
  78.  
  79.  
  80. -- The Answer V3.00
  81.